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DETAILED ACTION 

1 . This Office action is in response to the RCE filed on October 19, 2007. 

2. Claims 42-80 are pending. 

3. Claims 42, 46, 52, 56, 62, 66, 72, and 75 have been amended. 

4. Claims 1-41 have been cancelled. 

5. The objection to the specification is withdrawn in view of Applicant's amendments to the 
specification. 

6. The objection to Claim 72 is withdrawn in view of Applicant's amendments to the claim. 

7. The 35 U.S.C. § 1 12, second paragraph, rejections of Claims 42-61, 66, 67, 75, and 76 
are withdrawn in view of Applicant's amendments to the claims. However, Applicant's 
amendments to Claims 62 and 72 fail to fully address the rejection due to insufficient antecedent 
basis. Accordingly, this rejection is maintained and further explained below. 

8. The 35 U.S.C. § 101 rejections of Claims 72-80 are withdrawn in view of Applicant's 
amendments to the claims. 

Response to Amendment 
Specification 

9. The title of the invention is not descriptive. A new title is required that is clearly 
indicative of the invention to which the claims are directed. 
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Claim Rejections - 35 USC § 112 

10. The following is a quotation of the second paragraph of 35 U.S.C. 1 12: 

The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the 
subject matter which the applicant regards as his invention. 

1 1 . Claims 62-80 are rejected under 35 U.S.C. 112, second paragraph, as being indefinite for 
failing to particularly point out and distinctly claim the subject matter which applicant regards as 
the invention. 

Claims 62 and 72 recite the limitation "the requirements." There is insufficient 
antecedent basis for this limitation in the claims. In the interest of compact prosecution, the 
Examiner subsequently interprets this limitation as reading "a set of requirements" for the 
purpose of further examination. 

Claims 63-71 depend on Claim 62 and, therefore, suffer the same deficiency as Claim 

62. 

Claims 73-80 depend on Claim 72 and, therefore, suffer the same deficiency as Claim 

72. 

Claim 72 recites the limitation "[a] computer readable medium comprising instructions." 
The claim is rendered indefinite because computer instructions can only be stored or recorded on 
a computer readable medium. In the interest of compact prosecution, the Examiner subsequently 
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interprets this limitation as reading "[a] computer readable medium storing instructions" for the 
purpose of further examination. 



Claims 73-80 depend on Claim 72 and, therefore, suffer the same deficiency as Claim 

72. 

Claim Rejections - 35 USC § 103 
12. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 



13. Claims 42-45, 49, 52-55, 59, 62-65, 69, 72-74, and 78 are rejected under 35 U.S.C. 
103(a) as being unpatentable over Eisenstein et al., "Applying Model-Based Techniques to 
the Development of UIs for Mobile Computers," 2001 (hereinafter "Eisenstein") in view of 
Puerta et al., "Towards a General Computational Framework for Model-Based Interface 
Development Systems," 1999 (hereinafter "Puerta"). 

As per Claim 42, Eisenstein discloses: 

- receiving a domain model, a user model, a task model, a device model, and a 
presentation elements library, wherein the domain model defines application requirements for 
which the user interface is to be used, wherein the user model defines user requirements of users 
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who are to interface with the user interface, wherein the task model defines task requirements of 
tasks to be performed between the user interface and users, wherein the device model defines 
interaction delivery devices that are available to deliver the user interface, and wherein the 
presentation elements library contains a set of display objects used to present information to or 
acquire information from a user of the user interface being designed (see Figure 2; Page 70, "A 
platform model describes the various computer systems that may run a UI. This model includes 
information regarding the constraints placed on the UI by the platform. The platform model 
contains an element for each platform that is supported, and each element contains attributes 
describing features and constraints. " and "A presentation model describes the visual 
appearance of the user interface. The presentation model includes information describing the 
hierarchy of windows and their widgets (e.g., sliders, list boxes), stylistic choices, and the 
selection and placement of these widgets. "; Page 71, "A task model is a structured 
representation of the tasks that the user of the software may want to perform. The task model is 
hierarchically decomposed into subtasks, and information regarding goals, preconditions, and 
postconditions may be supplied. " and "For many applications, it is essential to model the users 
themselves, especially when there are multiple users with different preferences, abilities, and ■. 
privileges. It is also often appropriate to model the domain characteristics of the tasks supported 
by the UI. Such information often guides the selection of widgets. "); 

- generating a set of presentations, wherein each presentation in the set of presentations 
comprises an interaction delivery device and a display object that meets a set of requirements of 
the interaction delivery device, wherein the interaction delivery device is selected from a set of 
interaction delivery devices in the device model that meets the task requirements defined by the 
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task model, and wherein the display object is selected from the set of display objects in the 
presentation elements library that meets the task requirements defined by the task model and the 
application requirements defined by the domain model (see Figures 2 and 3; Page 74, 'The 
designer should create mappings between platforms (or classes of platforms) and tasks (or sets 
of tasks). Additional mappings are then created between task elements and presentation 
structures that are optimized for a given set of tasks. We can assume these mappings are 
transitive; as a result, the appropriate presentation model is associated with each platform, 
based on mappings through the task model. and 

- displaying the set of presentations to a user interface designer (see Page 72, "Under 
our proposed architecture, it is still left to the interface designer to specify a set of alternative 
presentation structures. "). 

However, Eisenstein does not disclose: 

wherein the interaction delivery device is selected from a set of interaction delivery 
devices in the device model that meets the user requirements defined by the user model, and 
wherein the display object is selected from a set of display objects in the presentation elements 
library that meets the application requirements defined by the domain model. 

Puerta discloses: 

- wherein the interaction delivery device is selected from a set of interaction delivery 
devices in the device model that meets the user requirements defined by the user model, and 
wherein the display object is selected from a set of display objects in the presentation elements 
library that meets the application requirements defined by the domain model (see Page J 73, 
"Each user may be involved in all tasks in a user-task model, or just in a subset of these tasks. 
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The assignment of users to tasks is a mapping process. "; Page 1 74, "An interface model must 
also define what objects are involved in the completion of the tasks represented in its user-task 
model component. Thus it is necessary to map objects to tasks in an interface model. "). 

Therefore, it would have been obvious to one of ordinary skill in the art at the time the 
invention was made to incorporate the teaching of Puerta into the teaching of Eisenstein to 
include wherein the interaction delivery device is selected from a set of interaction delivery 
devices in the device model that meets the user requirements defined by the user model, and 
wherein the display object is selected from a set of display objects in the presentation elements 
library that meets the application requirements defined by the domain model. The modification 
would be obvious because one of ordinary skill in the art would be motivated to build and refine ; 

i 

the interface model to produce a user interface (see Puerta - Page 171). 

As per Claim 43, the rejection of Claim 42 is incorporated; and Eisenstein further 
discloses: 

- responsive to at least one input from the user interface designer, generating the user 
interface (see Figures 6 and 7). 

As per Claim 44, the rejection of Claim 42 is incorporated; and Eisenstein further 
discloses: 

wherein generating a set of presentations is performed by a reasoning engine (see 
Figure 3; Page 72, "This mediator should determine the maximum usable screen resolution for 
the relevant device, and evaluate the amount of screen resolution required by each presentation 
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structure alternative. It can then select the presentation structure that consumes an amount of 
screen resolution that falls just under the maximum (fig. 3). "). 

As per Claim 45, the rejection of Claim 42 is incorporated; and Eisenstein further 
discloses: 

- matching capabilities of the interactive delivery devices in the device model to task 
requirements defined in the task model (see Figure 5; Page 74, "The designer should create 
mappings between platforms (or classes of platforms) and tasks (or sets of tasks). Additional 
mappings are then created between task elements and presentation structures that are optimized 
for a given set of tasks. We can assume these mappings are transitive; as a result, the 
appropriate presentation model is associated with each platform, based on mappings through 
the task model. ")\ and 

- matching capabilities of display objects in the presentation elements library to task 
requirements defined in the task model (see Figure 5; Page 74, "Additional mappings are then 
created between task elements and presentation structures that are optimized for a given set of 
tasks. "). 

However, Eisenstein does not disclose: 

- matching capabilities of the interactive delivery devices in the device model to user 
requirements defined in the user model; and 

- matching capabilities of display objects in the presentation elements library to 
application requirements defined in the domain model. 

Puerta discloses: 
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- matching capabilities of the interactive delivery devices in the device model to user 
requirements defined in the user model (see Page 1 73, "Each user may be involved in all tasks in 
a user-task model or just in a subset of these tasks. The assignment of users to tasks is a 
mapping process. ")\ and 

- matching capabilities of display objects in the presentation elements library to 
application requirements defined in the domain model (see Page 1 74, "An interface model must 
also define what objects are involved in the completion of the tasks represented in its user-task 
model component. Thus it is necessary to map objects to tasks in an interface model "). 

Therefore, it would have been obvious to one of ordinary skill in the art at the time the 
invention was made to incorporate the teaching of Puerta into the teaching of Eisenstein to 
include matching capabilities of the interactive delivery devices in the device model to user 
requirements defined in the user model; and matching capabilities of display objects in the 
presentation elements library to application requirements defined in the domain model. The 
modification would be obvious because one of ordinary skill in the art would be motivated to 
build and refine the interface model to produce a user interface (see Puerta - Page I 71), 

As per Claim 49, the rejection of Claim 42 is incorporated; and Eisenstein further 
discloses: 

- wherein the domain model, the user model, the task model, and the device model are 
expressed in a common notation format (see Page 70, "The MIMIC modeling language meets 
these criteria, and it is the language we have chosen to use for U I modeling. "). 
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As per Claim 52, Eisenstein discloses: 

- creating a domain model, a user model, a task model, a device model, and a 
presentation elements library, wherein the domain model defines application requirements for 
which the user interface is to be used, wherein the user model defines user requirements of users 
who are to interface with the user interface, wherein the task model defines task requirements of 
tasks to be performed between the user interface and users, wherein the device model defines 
interaction delivery devices that are available to deliver the user interface, and wherein the 
presentation elements library contains a set of display objects used to present information to or 
acquire information from a user of the user interface being designed (see Figure 2; Page 70, "A 
platform model describes the various computer systems that may run a UI. This model includes 
information regarding the constraints placed on the UI by the platform. The platform model 
contains an element for each platform that is supported, and each element contains attributes 
describing features and constraints. " and "A presentation model describes the visual 
appearance of the user interface. The presentation model includes information describing the 
hierarchy of windows and their widgets (e.g., sliders, list boxes), stylistic choices, and the 
selection and placement of these widgets. "; Page 71, "A task model is a structured 
representation of the tasks that the user of the software may want to perform. The task model is 
hierarchically decomposed into subtasks, and information regarding goals, preconditions, and 
postconditions may be supplied. " and t( For many applications, it is essential to model the users 
themselves, especially when there are multiple users with different preferences, abilities, and 
privileges. It is also often appropriate to model the domain characteristics of the tasks supported 
by the UI Such information often guides the selection of widgets. 
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- generating a set of presentations, wherein each presentation in the set of presentations 
comprises an interaction delivery device and a display object that meets a set of requirements of 
the interaction delivery device, wherein the interaction delivery device is selected from a set of 
interaction delivery devices in the device model that meets the task requirements defined by the 
task model, and wherein the display object is selected from the set of display objects in the 
presentation elements library that meets the task requirements defined by the task model and the 
application requirements defined by the domain model (see Figures 2 and 3; Page 74, 'The 
designer should create mappings between platforms (or classes of platforms) and tasks (or sets 
of tasks). Additional mappings are then created between task elements and presentation 
structures that are optimized for a given set of tasks. We can assume these mappings are 
transitive; as a result, the appropriate presentation model is associated with each platform, 
based on mappings through the task model. ")\ and 

- displaying the set of presentations to a user interface designer (see Page 72, "Under 
our proposed architecture, it is still left to the interface designer to specify a set of alternative 
presentation structures. "). 

However, Eisenstein does not disclose: 

storing the domain model, user model, task model, device model, and presentation 
elements library into computer readable media; and 

- wherein the interaction delivery device is selected from a set of interaction delivery 
devices in the device model that meets the user requirements defined by the user model, and 
wherein the display object is selected from a set of display objects in the presentation elements 
library that meets the application requirements defined by the domain model. 
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Official Notice is taken that it is old and well-known within the computing art to store a 
computer program or components of the computer program in a computer readable media. In a 
computing system, components of a computer program are stored in a computer readable media 
so a processing unit may execute the instructions stored therein. Therefore, it would have been 
obvious to one of ordinary skill in the art at the time the invention was made to include storing 
the domain model, user model, task model, device model, and presentation elements library into 
computer readable media. The modification would be obvious because one of ordinary skill in 
the art would be motivated to execute the components of the computer program. 

Puerta discloses: 

- wherein the interaction delivery device is selected from a set of interaction delivery 
devices in the device model that meets the user requirements defined by the user model, and 
wherein the display object is selected from a set of display objects in the presentation elements 
library that meets the application requirements defined by the domain model (see Page 1 73, 
"Each user may be involved in all tasks in a user-task model, or just in a subset of these tasks. 
The assignment of users to tasks is a mapping process. "; Page J 74, "An interface model must 
also define what objects are involved in the completion of the tasks represented in its user-task 
model component. Thus it is necessary to map objects to tasks in an interface model. "). 

Therefore, it would have been obvious to one of ordinary skill in the art at the time the 
invention was made to incorporate the teaching of Puerta into the teaching of Eisenstein to 
include wherein the interaction delivery device is selected from a set of interaction delivery 
devices in the device model that meets the user requirements defined by the user model, and 
wherein the display object is selected from a set of display objects in the presentation elements 
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library that meets the application requirements defined by the domain model. The modification 
would be obvious because one of ordinary skill in the art would be motivated to build and refine 
the interface model to produce a user interface (see Puerta - Page 1 71). 

As per Claim 53, the rejection of Claim 52 is incorporated; and Eisenstein further 
discloses: 

- responsive to at least one input from the user interface designer, generating the user 
interface (see Figures 6 and 7). 

As per Claim 54, the rejection of Claim 52 is incorporated; and Eisenstein further 
discloses: 

wherein generating a set of presentations is performed by a reasoning engine (see 
Figure 3; Page 72, (( This mediator should determine the maximum usable screen resolution for 
the relevant device, and evaluate the amount of screen resolution required by each presentation 
structure alternative. It can then select the presentation structure that consumes an amount of 
screen resolution that falls just under the maximum (fig. 3). "). 

As per Claim 55, the rejection of Claim 52 is incorporated; and Eisenstein further 
discloses: 

matching capabilities of the interactive delivery devices in the device model to task 
requirements defined in the task model (see Figure 5; Page 74, 'The designer should create 
mappings between platforms (or classes of platforms) and tasks (or sets of tasks). Additional 
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mappings are then created between task elements and presentation structures that are optimized 
for a given set of tasks. We can assume these mappings are transitive; as a result, the 
appropriate presentation model is associated with each platform, based on mappings through 
the task model and 

- . matching capabilities of display objects in the presentation elements library to task 
requirements defined in the task model (see Figure 5; Page 74, "Additional mappings are then 
created between task elements and presentation structures that are optimized for a given set of 
tasks. "). 

However, Eisenstein does not disclose: 

- matching capabilities of the interactive delivery devices in the device model to user 
requirements defined in the user model; and 

- matching capabilities of display objects in the presentation elements library to 
application requirements defined in the domain model. 

Puerta discloses: 

- matching capabilities of the interactive delivery devices in the device model to user 
requirements defined in the user model (see Page 1 73, "Each user may be involved in all tasks in 
a user-task model, or just in a subset of these tasks. The assignment of users to tasks is a 
mapping process. and 

- matching capabilities of display objects in the presentation elements library to 
application requirements defined in the domain model (see Page 1 74, "An interface model must 
also define what objects are involved in the completion of the tasks represented in its user-task 
model component. Thus it is necessary to map objects to tasks in an interface model "). 
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Therefore, it would have been obvious to one of ordinary skill in the art at the time the 
invention was made to incorporate the teaching of Puerta into the teaching of Eisenstein to 
include matching capabilities of the interactive delivery devices in the device model to user 
requirements defined in the user model; and matching capabilities of display objects in the 
presentation elements library to application requirements defined in the domain model. The 
modification would be obvious because one of ordinary skill in the art would be motivated to 
build and refine the interface model to produce a user interface (see Puerta - Page 1 71). 

As per Claim 59, the rejection of Claim 52 is incorporated; and Eisenstein further 
discloses: 

- wherein the domain model, the user model, the task model, and the device model are 
expressed in a common notation format (see Page 70, "The MIMIC modeling language meets 
these criteria, and it is the language we have chosen to use for UI modeling, "). 

As per Claim 62, Eisenstein discloses: 

- wherein the domain model defines application requirements for which the user 
interface is to be used (see Page 71, "// is also often appropriate to model the domain 
characteristics of the tasks supported by the UI Such information often guides the selection of 
widgets. 11 )\ 

- wherein the user model defines user requirements of users who are to interface with 
the user interface (see Page 71, "For many applications, it is essential to model the users 
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themselves, especially when there are multiple users with different preferences, abilities, and 
privileges. "); 

- wherein the task model defines task requirements of tasks to be performed between 
the user interface and users who are to interface with the user interface (see Page 71, "A task 
model is a structured representation of the tasks that the user of the software may want to 
perform. The task model is hierarchically decomposed into subtasks, and information regarding 
goals, preconditions, and postconditions may be supplied. 

- wherein the device model defines interaction delivery devices that are available to 
deliver the user interface (see Page 70, "A platform model describes the various computer 
systems that may run a UI. This model includes information regarding the constraints placed on 
the UI by the platform. The platform model contains an element for each platform that is 
supported, and each element contains attributes describing features and constraints. 

- wherein the presentation elements library contains a set of display objects used to 
present information to or acquire information from a user of the user interface being designed 
(see Figure 2; Page 70, "A presentation model describes the visual appearance of the user 
interface. The presentation model includes information describing the hierarchy of windows and 
their widgets (e.g., sliders, list boxes), stylistic choices, and the selection and placement of these 
widgets. ")\ 

- generating a set of presentations, wherein each presentation in the set of presentations 
comprises an interaction delivery device and a display object that meets a set of requirements of 
the interaction delivery device, wherein the interaction delivery device is selected from a set of 
interaction delivery devices in the device model that meets the task requirements defined by the 
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task model, and wherein the display object is selected from the set of display objects in the 
presentation elements library that meets the task requirements defined by the task model and the 
application requirements defined by the domain model (see Figures 2 and 3; Page 74, "The 
designer should create mappings between platforms (or classes of platforms) and tasks (or sets 
of tasks). Additional mappings are then created between task elements and presentation 
structures that are optimized for a given set of tasks. We can assume these mappings are 
transitive; as a result, the appropriate presentation model is associated with each platform, 
based on mappings through the task model "); and 

- displaying the set of presentations to a user interface designer (see Page 72, "Under 
our proposed architecture, it is still left to the interface designer to specify a set of alternative 
presentation structures. "). 

However, Eisenstein does not disclose: 

- storing a domain model, a user model, a task model, a device model, and a 
presentation elements library into computer readable media; and 

- wherein the interaction delivery device is selected from a set of interaction delivery 
devices in the device model that meets the user requirements defined by the user model, and 
wherein the display object is selected from a set of display objects in the presentation elements 
library that meets the application requirements defined by the domain model. 

Official Notice is taken that it is old and well-known within the computing art to store a 
computer program or components of the computer program in a computer readable media. In a 
computing system, components of a computer program are stored in a computer readable media 
so a processing unit may execute the instructions stored therein. Therefore, it would have been 
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obvious to one of ordinary skill in the art at the time the invention was made to include storing a 
domain model, a user model, a task model, a device model, and a presentation elements library 
into computer readable media. The modification would be obvious because one of ordinary skill 
in the art would be motivated to execute the components of the computer program. 
Puerta discloses: 

- wherein the interaction delivery device is selected from a set of interaction delivery 
devices in the device model that meets the user requirements defined by the user model, and 
wherein the display object is selected from a set of display objects in the presentation elements 
library that meets the application requirements defined by the domain model (see Page 1 73, 
"Each user may be involved in all tasks in a user -task model or just in a subset of these tasks. 
The assignment of users to tasks is a mapping process. Page 174, "An interface model must 
also define what objects are involved in the completion of the tasks represented in its user-task 
model component. Thus it is necessary to map objects to tasks in an interface model "). 

Therefore, it would have been obvious to one of ordinary skill in the art at the time the 
invention was made to incorporate the teaching of Puerta into the teaching of Eisenstein to 
include wherein the interaction delivery device is selected from a set of interaction delivery 
devices in the device model that meets the user requirements defined by the user model, and . 
wherein the display object is selected from a set of display objects in the presentation elements 
library that meets the application requirements defined by the domain model. The modification 
would be obvious because one of ordinary skill in the art would be motivated to build and refine 
the interface model to produce a user interface (see Puerta - Page 1 71). 
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As per Claim 63, the rejection of Claim 62 is incorporated; and Eisenstein further 
discloses: 

- responsive to at least one input from the user interface designer, generating the user 
interface (see Figures 6 and 7). 

As per Claim 64, the rejection of Claim 62 is incorporated; and Eisenstein further 
discloses: 

- wherein generating a set of presentations is performed by a reasoning engine (see 
Figure 3; Page 72, "This mediator should determine the maximum usable screen resolution for 
the relevant device, and evaluate the amount of screen resolution required by each presentation 
structure alternative. It can then select the presentation structure that consumes an amount of 
screen resolution that falls just under the maximum (fig. 3). "). 

As per Claim 65, the rejection of Claim 62 is incorporated; and Eisenstein further 
discloses: 

- matching capabilities of the interactive delivery devices in the device model to task 
requirements defined in the task model (see Figure 5; Page 74, "The designer should create 
mappings between platforms (or classes of platforms) and tasks (or sets of tasks). Additional 
mappings are then created between task elements and presentation structures that are optimized 
for a given set of tasks. We can assume these mappings are transitive; as a result, the 
appropriate presentation model is associated with each platform, based on mappings through 
the task model ")\ and 
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- matching capabilities of display objects in the presentation elements library to task 
requirements defined in the task model (see Figure 5; Page 74, "Additional mappings are then 
created between task elements and presentation structures that are optimized for a given set of 
tasks. "). 

However, Eisenstein does not disclose: 

- matching capabilities of the interactive delivery devices in the device model to user 
requirements defined in the user model; and 

- matching capabilities of display objects in the presentation elements library to 
application requirements defined in the domain model. 

Puerta discloses: 

- matching capabilities of the interactive delivery devices in the device model to user 
requirements defined in the user model (see Page 173, "Each user may be involved in all tasks in 
a user-task model or just in a subset of these tasks. The assignment of users to tasks is a 
mapping process. ")\ and 

- matching capabilities of display objects in the presentation elements library to 
application requirements defined in the domain model (see Page 174, "An interface model must 
also define what objects are involved in the completion of the tasks represented in its user-task 
model component. Thus it is necessary to map objects to tasks in an interface model. "). 

Therefore, it would have been obvious to one of ordinary skill in the art at the time the 
invention was made to incorporate the teaching of Puerta into the teaching of Eisenstein to 
include matching capabilities of the interactive delivery devices in the device model to user 
requirements defined in the user model; and matching capabilities of display objects in the 
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presentation elements library to application requirements defined in the domain model. The 
modification would be obvious because one of ordinary skill in the art would be motivated to 
build and refine the interface model to produce a user interface (see Puerta - Page 1 11). 

As per Claim 69, the rejection of Claim 62 is incorporated; and Eisenstein further 
discloses: 

- wherein the domain model, the user model, the task model, and the device model are 
expressed in a common notation format (see Page 70, "The MIMIC modeling language meets 
these criteria, and it is the language we have chosen to use for U I modeling. "). 

Claims 72-74 and 78 are computer readable medium claims corresponding to the method 
claims above (Claims 42, 43, 45, and 49) and, therefore, are rejected for the same reasons set 
forth in the rejections of Claims 42, 43, 45, and 49. 

14. Claims 46-48, 56-58, 66-68, and 75-77 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Eisenstein in view of Puerta as applied to Claims 42, 52, 62, and 72 above, 
and further in view of US 6,243,713 (hereinafter "Nelson"). 



As per Claim 46, the rejection of Claim 42 is incorporated; however, Eisenstein and 
Puerta do not disclose: 
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- wherein generating a set of presentations further comprises scoring each presentation 
based at least in part on the application requirements defined in the domain model, the user 
requirements defined in the user model, and the task requirements defined in the task model. 

Nelson discloses: 

wherein generating a set of presentations further comprises scoring each presentation 
based at least in part on the application requirements defined in the domain model, the user 
requirements defined in the user model, and the task requirements defined in the task model (see 
Column 26: 44-48, "Once all candidate documents are scored, the final scores are sorted, and 
the documents presented to the user, providing the best scoring documents first. A threshold may 
be used to select a limited number of the best scoring documents if desired. "). 

Therefore, it would have been obvious to one of ordinary skill in the art at the time the 
invention was made to incorporate the teaching of Nelson into the teaching of Eisenstein to 
include wherein generating a set of presentations further comprises scoring each presentation 
based at least in part on the application requirements defined in the domain model, the user 
requirements defined in the user model, and the task requirements defined in the task model. The 
modification would be obvious because one of ordinary skill in the art would be motivated to 
enhance usability. 

As per Claim 47, the rejection of Claim 46 is incorporated; however, Eisenstein and 
Puerta do not disclose: 

sorting each presentation according to its score. 
Nelson discloses: 
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- sorting each presentation according to its score (see Column 26: 44-48, "Once all 
candidate documents are scored, the final scores are sorted, and the documents presented to the 
user, providing the best scoring documents first. A threshold may be used to select a limited 
number of the best scoring documents if desired, "). 

Therefore, it would have been obvious to one of ordinary skill in the art at the time the 
invention was made to incorporate the teaching of Nelson into the teaching of Eisenstein to 
include sorting each presentation according to its score. The modification would be obvious 
because one of ordinary skill in the art would be motivated to enhance usability. 

As per Claim 48, the rejection of Claim 42 is incorporated; however, Eisenstein and 
Puerta do not disclose: 

wherein displaying the set of presentations to a user interface designer further 
comprises displaying each presentation in a ranked list according to score. 

Nelson discloses: 

- wherein displaying the set of presentations to a user interface designer further 
comprises displaying each presentation in a ranked list according to score (see Column 26: 44- 
48, "Once all candidate documents are scored, the final scores are sorted, and the documents 
presented to the user, providing the best scoring documents first' A threshold may be used to 
select a limited number of the best scoring documents if desired, 

Therefore, it would have been obvious to one of ordinary skill in the art at the time the 
invention was made to incorporate the teaching of Nelson into the teaching of Eisenstein to 
include wherein displaying the set of presentations to a user interface designer further comprises 
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displaying each presentation in a ranked list according to score. The modification would be 
obvious because one of ordinary skill in the art would be motivated to enhance usability. 

As per Claim 56, the rejection of Claim 52 is incorporated; however, Eisenstein and 
Puerta do not disclose: 

- wherein generating a set of presentations further comprises scoring each presentation 
based at least in part on the application requirements defined in the domain model, the user 
requirements defined in the user model, and the task requirements defined in the task model. 

Nelson discloses: 

- wherein generating a set of presentations further comprises scoring each presentation 
based at least in part on the application requirements defined in the domain model, the user 
requirements defined in the user model, and the task requirements defined in the task model (see 
Column 26: 44-48, "Once all candidate documents are scored, the final scores are sorted, and 
the documents presented to the user, providing the best scoring documents first. A threshold may 
be used to select a limited number of the best scoring documents if desired. "). 

Therefore, it would have been obvious to one of ordinary skill in the art at the time the 
invention was made to incorporate the teaching of Nelson into the teaching of Eisenstein to 
include wherein generating a set of presentations further comprises scoring each presentation 
based at least in part on the application requirements defined in the domain model, the user 
requirements defined in the user model, and the task requirements defined in the task model. The 
modification would be obvious because one of ordinary skill in the art would be motivated to 
enhance usability. 
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As per Claim 57, the rejection of Claim 56 is incorporated; however, Eisenstein and 
Puerta do not disclose: 

sorting each presentation according to its score. 
Nelson discloses: 

sorting each presentation according to its score (see Column 26: 44-48, "Once all 
candidate documents are scored, the final scores are sorted, and the documents presented to the 
user, providing the best scoring documents first. A threshold may be used to select a limited 
number of the best scoring documents if desired. "). 

Therefore, it would have been obvious to one of ordinary skill in the art at the time the 
invention was made to incorporate the teaching of Nelson into the teaching of Eisenstein to 
include sorting each presentation according to its score. The modification would be obvious 
because one of ordinary skill in the art would be motivated to enhance usability. 

As per Claim 58, the rejection of Claim 52 is incorporated; however, Eisenstein and 
Puerta do not disclose: 

- wherein displaying the set of presentations to a user interface designer further 
comprises displaying each presentation in a ranked list according to score. 

Nelson discloses: 

- wherein displaying the set of presentations to a user interface designer further 
comprises displaying each presentation in a ranked list according to score (see Column 26: 44- 
48, "Once all candidate documents are scored, the final scores are sorted, and the documents 
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presented to the user, providing the best scoring documents first. A threshold may be used to 
select a limited number of the best scoring documents if desired. "). 

Therefore, it would have been obvious to one of ordinary skill in the art at the time the 
invention was made to incorporate the teaching of Nelson into the teaching of Eisenstein to 
include wherein displaying the set of presentations to a user interface designer further comprises 
displaying each presentation in a ranked list according to score. The modification would be 
obvious because one of ordinary skill in the art would be motivated to enhance usability. 

As per Claim 66, the rejection of Claim 62 is incorporated; however, Eisenstein and 
Puerta do not disclose: 

- wherein generating a set of presentations further comprises scoring each presentation 
based at least in part on the application requirements defined in the domain model, the user 
requirements defined in the user model, and the task requirements defined in the task model 

Nelson discloses: 

- wherein generating a set of presentations further comprises scoring each presentation 
based at least in part on the application requirements defined in the domain model, the user 
requirements defined in the user model, and the task requirements defined in the task model (see 
Column 26: 44-48, "Once all candidate documents are scored, the final scores are sorted, and 
the documents presented to the user, providing the best scoring documents first. A threshold may 
be used to select a limited number of the best scoring documents if desired. "). 

Therefore, it would have been obvious to one of ordinary skill in the art at the time the 
invention was made to incorporate the teaching of Nelson into the teaching of Eisenstein to 
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include wherein generating a set of presentations further comprises scoring each presentation 
based at least in part on the application requirements defined in the domain model, the user 
requirements defined in the user model, and the task requirements defined in the task model. The 
modification would be obvious because one of ordinary skill in the art would be motivated to 
enhance usability. 

As per Claim 67, the rejection of Claim 66 is incorporated; however, Eisenstein and 
Puerta do not disclose: 

- sorting each presentation according to its score. 
Nelson discloses: 

- sorting each presentation according to its score (see Column 26: 44-48, "Once all 
candidate documents are scored, the final scores are sorted, and the documents presented to the 
user, providing the best scoring documents first. A threshold may be used to select a limited 
number of the best scoring documents if desired. "). 

Therefore, it would have been obvious to one of ordinary skill in the art at the time the 
invention was made to incorporate the teaching of Nelson into the teaching of Eisenstein to 
include sorting each presentation according to its score. The modification would be obvious 
because one of ordinary skill in the art would be motivated to enhance usability. 



As per Claim 68, the rejection of Claim 62 is incorporated; however, Eisenstein and 
Puerta do not disclose: 
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- wherein displaying the set of presentations to a user interface designer further 
comprises displaying each presentation in a ranked list according to score. 

Nelson discloses: 

- wherein displaying the set of presentations to a user interface designer further 
comprises displaying each presentation in a ranked list according to score (see Column 26: 44- 
48, "Once all candidate documents are scored, the final scores are sorted, and the documents 
presented to the user, providing the best scoring documents first. A threshold may be used to 
select a limited number of the best scoring documents if desired. "). 

Therefore, it would have been obvious to one of ordinary skill in the art at the time the 
invention was made to incorporate the teaching of Nelson into the teaching of Eisenstein to 
include wherein displaying the set of presentations to a user interface designer further comprises 
displaying each presentation in a ranked list according to score. The modification would be 
obvious because one of ordinary skill in the art would be. motivated to enhance usability. 

Claims 75-77 are rejected for the same reasons set forth in the rejections of Claims 46- 

48. 

15. Claims 50, 60, 70, and 79 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Eisenstein in view of Puerta as applied to Claims 49, 59, 69, and 78 above, and further in 
view of "Resource Description Framework (RDF) Model and Syntax," 1997 (hereinafter 
"RDF1997"). 
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As per Claim 50, the rejection of Claim 49 is incorporated; however, Eisenstein and 
Puerta do not disclose: 

- wherein the common notation format adheres to the Resource Description Framework 
specification. 

RDF 1997 discloses: 

- wherein the common notation format adheres to the Resource Description Framework 
specification (see Section 7, " RDF metadata can be used in a variety of application areas ... 99 ). 

Therefore, it would have been obvious to one of ordinary skill in the art at the time the 
invention was made to incorporate the teaching of RDF 1997 into the teaching of Eisenstein to 
include wherein the common notation format adheres to the Resource Description Framework 
specification. The modification would be obvious because one of ordinary skill in the art would 
be motivated to provide interoperability between applications that exchange machine 
understandable information on the Web (see RDF 1997 - Section J). 

As per Claim 60, the rejection of Claim 59 is incorporated; however, Eisenstein and 
Puerta do not disclose: 

- wherein the common notation format adheres to the Resource Description Framework 
specification. 

RDF 1997 discloses: 

- wherein the common notation format adheres to the Resource Description Framework 
specification (see Section 7, "RDF metadata can be used in a variety of application areas ... "). 
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Therefore, it would have been obvious to one of ordinary skill in the art at the time the 
invention was made to incorporate the teaching of RDF 1997 into the teaching of Eisenstein to 
include wherein the common notation format adheres to the Resource Description Framework 
specification. The modification would be obvious because one of ordinary skill in the art would 
be motivated to provide interoperability between applications that exchange machine 
understandable information on the Web (see RDF 1997 - Section 1). 

As per Claim 70, the rejection of Claim 69 is incorporated; however, Eisenstein and 
Puerta do not disclose: 

- wherein the common notation format adheres to the Resource Description Framework 
specification. 

RDF 1997 discloses: 

- wherein the common notation format adheres to the Resource Description Framework 
specification (see Section 1, "RDF metadata can be used in a variety of application areas ... "). 

Therefore, it would have been obvious to one of ordinary skill in the art at the time the 
invention was made to incorporate the teaching of RDF 1997 into the teaching of Eisenstein to 
include wherein the common notation format adheres to the Resource Description Framework 
specification. The modification would be obvious because one of ordinary skill in the art would 
be motivated to provide interoperability between applications that exchange machine 
understandable information on the Web (see RDF 1997 - Section 1). 



Claim 79 is rejected for the same reason set forth in the rejection of Claim 50. 
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16. Claims 51, 61, 71, and 80 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Eisenstein in view of Puerta as applied to Claims 42, 52, 62, and 72 above, and further in 
view of "Extensible Markup Language (XML) 1.0," 1998 (hereinafter "XML1998"). 

As per Claim 51, the rejection of Claim 42 is incorporated; however, Eisenstein and 
Puerta do not disclose: 

- wherein each presentation is an XML file. 
XML 1998 discloses: 

- wherein each presentation is an XML file (see Section 7, " Extensible Markup 
Language, abbreviated XML, describes a class of data objects called XML documents and 
partially describes the behavior of computer programs which process them. "). 

Therefore, it would have been obvious to one of ordinary skill in the art at the time the 
invention was made to incorporate the teaching of XML 1998 into the teaching of Eisenstein to 
include wherein each presentation is an XML file. The modification would be obvious because 
one of ordinary skill in the art would be motivated to support a wide variety of applications (see 
XML 1998 - Section LI). 

As per Claim 61, the rejection of Claim 52 is incorporated; however, Eisenstein and 
Puerta do not disclose: 

- wherein each presentation is an XML file.- 
XML 1998 discloses: 
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- wherein each presentation is an XML file (see Section 1, "Extensible Markup 
Language, abbreviated XML, describes a class of data objects called XML documents and 
partially describes the behavior of computer programs which process them. "). 

Therefore, it would have been obvious to one of ordinary skill in the art at the time the 
invention was made to incorporate the teaching of XML 1998 into the teaching of Eisenstein to 
include wherein each presentation is an XML file. The modification would be obvious because 
one of ordinary skill in the art would be motivated to support a wide variety of applications (see 
XML1998 - Section LI). 

As per Claim 71, the rejection of Claim 62 is incorporated; however, Eisenstein and 
Puerta do not disclose: 

- wherein each presentation is an XML file. 
XML 1998 discloses: 

- wherein each presentation is an XML file (see Section 1, "Extensible Markup 
Language, abbreviated XML, describes a class of data objects called XML documents and 
partially describes the behavior of computer programs which process them. 

Therefore, it would have been obvious to one of ordinary skill in the art at the time the 
invention was made to incorporate the teaching of XML 1998 into the teaching of Eisenstein to 
include wherein each presentation is an XML file. The modification would be obvious because 
one of ordinary skill in the art would be motivated to support a wide variety of applications (see 
XML1998 - Section 1.1). 
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Claim 80 is rejected for the same reason set forth in the rejection of Claim 51. 

Response to Arguments 
1 7. Applicant's arguments filed on October 19, 2007 have been fully considered, but they are 
not persuasive. 

In the remarks, Applicant argues that: 

a) In the Office Action, the Examiner alleged that Eisenstein's disclosed platform model was 
equivalent to the claimed device model. According to Eisenstein, a "platform model describes 
the various computer systems that may run a UI... The platform model contains an element for 
each platform that is supported, and each element contains attributes describing features and 
constraints." (Eisenstein at 70) As examples of platforms, Eisenstein lists palmtop computers, 
laptop computers, and desktop computers. 

In contrast, Applicant's device model characterizes interaction delivery devices to support 
a UI. Quite simply, Eisenstein has nothing to do with interaction delivery devices. The 
Applicant's interaction delivery devices include, for example, specifications and characteristics 
of interactive delivery devices that may be used to deliver a UI being designed, when the UI is 
invoked by an application. These specifications may include capabilities and modalities that are 
supported by the available interaction delivery devices relevant to the application. The 
capabilities may include bandwidth, memory, screen, line of display, width of display, 
illumination, etc. The modalities may include visual, audible, etc. (See Applicants' Specification, 
par. 0039). 
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While Eisenstein's platform model focuses on computer systems used to present the UI to 
the user, it in no way involves delivery of the UI or modalities employed by the UIs. Therefore, 
Eisenstein does not disclose or suggest Applicants' device model. 



Examiner's response: 

a) Applicant asserts that the platform model of Eisenstein does not involve in the delivery 
(emphasis in original) of the UI or modalities employed by the UIs. Examiner disagrees. The 
term "delivery" is not defined by the claims nor does the specification provide any clarification 
for ascertaining the requisite meaning. It is understood that Applicants can be their own 
lexicographers. According to MPEP § 2173.01, they can define in the claims what they regard as 
their invention essentially in whatever terms they choose so long as any special meaning 
assigned to a term is clearly set forth in the specification. The particular section of interest of the 
MPEP is reproduced below with emphasis added for Applicant's convenience: 
2173.01 [R-2] Claim Terminology 

A fundamental principle contained in 35 U.S.C. 1 12, second paragraph is that 
applicants are their own lexicographers. They can define in the claims what they 
regard as their invention essentially in whatever terms they choose so long as 
**>any special meaning assigned to a term is clearly set forth in the specification. 
See MPEP § 21 1 1.01. < Applicant may use functional language, alternative 
expressions, negative limitations, or any style of expression or format of claim 
which makes clear the boundaries of the subject matter for which protection is 
sought. As noted by the court in In re Swinehart, 439 F.2d 210, 160 USPQ 226 
(CCPA 1971), a claim may not be rejected solely because of the type of language 
used to define the subject matter for which patent protection is sought. 

The specification (namely, paragraph 39 on page 23, lines 3-14) lacks any clarification on 

the claim scope of the term "delivery" as intended by the Applicant to cover. The noted 

paragraph merely lists the various capabilities and modalities that are part of an interaction 
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delivery device's specification. Thus, absent such an explicit and deliberate definition for the 
term "delivery," it is treated under the broadest reasonable interpretation. And accordingly, the 
platform model of Eisenstein describes the various computer systems (interaction delivery 
devices) that may run a UI (deliver the user interface). One of ordinary skill in the art would 
clearly associate the platform model of Eisenstein with the device model as required by the 
claim. 

Furthermore, the plain language of the claim expressly recites that the device model 
"defines interaction delivery devices that are available to deliver the user interface." The claim 
scope does not require the additional limitation of "specifications and characteristics of the 
interactive delivery devices that may be used to deliver a UI being designed" and other 
limitations pertaining to the device model and interaction delivery devices from the specification. 
Although the claims are interpreted in light of the specification, limitations from the specification 
are not read into the claims. See In re Van Geuns, 988 F.2d 1 181, 26 USPQ2d 1057 (Fed. Cir. 
1993). 

For at least the reasons set forth above, the rejections made under 35 U.S.C. 103(a) over 
the prior art of record with regard to Claims 42, 52, 62, and 72 are proper and, therefore, 
maintained. 

Note that Applicant did not traverse the Examiner's assertion of Official Notice with 
regard to Claims 52 and 62. Therefore, the "old and well-known within the computing art" 
statement is taken to be admitted prior art because Applicant has failed to traverse the 
Examiner's assertion of Official Notice (see MPEP § 2144.03). 
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Conclusion 

1 8. The prior art made of record and not relied upon is considered pertinent to Applicant's 
disclosure. 

Any inquiry concerning this communication or earlier communications from the 
Examiner should be directed to Qing Chen whose telephone number is 571-270-1071. The 
Examiner can normally be reached on Monday through Thursday from 7:30 AM to 4:00 PM. 
The Examiner can also be reached on alternate Fridays. 

If attempts to reach the Examiner by telephone are unsuccessful, the Examiner's 
supervisor, Wei Zhen, can be reached on 571-272-3708. The fax phone number for the 
organization where this application or proceeding is assigned is 571-273-8300. 

Any inquiry of a general nature or relating to the status of this application or proceeding 
should be directed to the TC 2100 Group receptionist whose telephone number is 571-272-2100. 

Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 
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